Team Update - 2012-03-13

Nothing game changing, just a warning about CPU usage on the cRIO and Driver’s Station.

GAME
Caution about CPU Usage

During the first two weeks we have observed a substantial number of teams with communications issues caused by CPU saturation. Saturating the CPU on either your cRIO or Driver’s Station computer can compromise your communications and cause your robot response to lag or drop completely. cRIO CPU usage can be monitored via the Driver’s Station Charts tab or the Driver Station Log File Viewer, more information on this utility is available on the Driver Station Kit of Parts page. Driver’s Station CPU usage can be viewed using the Task Manager by pressing Ctrl+Shift+Esc.

As a reminder, wireless control of robots in the pits is prohibited per section 4.3.1 of the Administrative manual. Additionally, we would highly recommend teams to connect to their DAP 1522 Robot Radio via Ethernet when tethering in the pits and leave the cRIO to Robot Radio connection in place.

Good luck in Week 3!

Honestly, I am shocked that the GDC is not weighing in on the events that happened at GTR. By not updating the rules, are they condoning them?

They’re probably still discussing it. At least, I hope they are.

I’m sure they’re no condoning it, but I think making touching the co-op bridge while teams are balancing illegal is going to be a little counter productive. The point is to get teams to cooperate. By making it illegal for teams to interfere in it, they’re still going against the SPIRIT of FIRST, but you’re taking some team’s opinions/input out of the coopertition bridge.

Not that I want to start an argument about it…

-Leeland

They could simply append a blue box saying that interfering with a coopertition balance is against the spirit of the game. It wouldn’t need to have a penalty associated with it. If they wanted one, it could be “Strategies aimed at interfering with a coopertition balance are not in the spirit of the FRC and are not allowed” Violation: Red Card

I assume that 3-4 days of talk was not enough for the GDC to reach a satisfactory, definite, solid conclusion on how to address GTR-East.

It might just be that the GDC chooses not to comment on this one. I can only think of one time they’ve changed a rule due to a team’s actions (the infamous WildStang Stack of '07), and I don’t think there’s a good way to change this rule.

Frankly, if the reaction was any indication, the heaps of scorn placed on a team trying such a stunt should be deterrent enough.

Didnt 190 get ruled illegal in 2008 after their 1st regional?

Not to derail, but anyone care to explain the infamous robots in 2007 and 2008? I would love to learn about them.

Here’s the 2007 one. http://www.thebluealliance.com/match/2007il_qm42

Here’s the 2008 one. http://www.thebluealliance.com/match/2008nh_qm45

Those are both so ingenious it hurts.

I think I missed something. Why did they ban 190’s design? It didn’t seem to make them more effective than any of the other robots there.

It was explicitly banned via Q&A before the competition season started, and then later clarified.

190’s “wrecking ball” design crossed the center divider into the other lane backwards. This was a penalty every time it was used (or should have been). It’s important to note that the design was ruled legal at one event, but that subsequent events found the design illegal. I forget what all else if anything was wrong with it; I think most of us were too busy looking at a different robot that was ruled illegal and going “How is that illegal?”, but that other robot could have been either way depending on rules interpretation.

In 2007, you scored endgame points by being atop your partners–in every other situation, it involved a ramp or lifting device. Back during build, I’d asked Q&A about starting the match with one partner atop the other…and given two robots that otherwise couldn’t contribute to the match, WildStang took advantage of the ruling to score 30 match-winning points. The next Tuesday, the GDC reversed their ruling and banned it going forward.

As I remember, 190’s issue was that the robot was ruled to cross the lane dividers and finish lines in the wrong sequence.

I’ve seen Team 190’s 2008 controversy mentioned several times in separate threads this year. I would like to correct some common errors:

The Q&A in question was the exact opposite, it seemed to indicate the design was legal before the season started, and was clarified after the SECOND regional to clarify that it was illegal. The Q&A question was posted in build week 2 by Team 2158, not Team 190.

190 presented their interpretation to members of the GDC and two regional head refs at the regional competitions.

I do not wish to derail this thread any more than it has been, so if anyone is interested in further details or the exact Q&A I am referring to, you can PM me. I do not know if it’s still accessible online.

I wasn’t going to post this until later, but the insane CPU usage I’ve seen this season has prompted me to release this now. I’ll do a more formal write up of this in a few days.

Basically, we found ourselves with robot code running near 97% all the time, and it was really messing with our timing. I looked through some of the deep internals of LabVIEW, and found that it’s actually quite inefficient in VI scheduling (assuming RT is the same; the documentation did not indicate any differences between LV desktop and LV RT) - In a nutshell, LabVIEW is running a tasking system for each VI, and queuing VI’s to run and such.

There are ways to improve efficiency (for example, simple VI’s can be set to Subroutine mode which optimizes the call, or you can optimize it further by setting re-entrant VI’s to be inlined into calling VI’s at compile time). Since you can’t use Subroutine priority for any call that causes the VI to be taken off of the execution queue because it locks the thread, you can’t contain any asynchronous statements (FPGA write, Wait, loops, etc.).

In my experience with the WPI library, I found that some specific systems were horribly unoptimized, requiring as many as 11 VI calls (in addition to the high-level call which the user sees) to set a motor. Times 10 motors, that’s over 120 VI executions every 20ms to handle the acts of scaling a decimal to U8 and passing it to the FPGA. The Motor library was the worst, as the MotorControl library passed data down into the PWM library which passed data down into the FPGA-PWM library, and every action contained a VI who’s only purpose was to change the dev ref bundle to match the lower level library’s bundle type.

I optimized the WPI Motor Set to remove all unnecessary VI calls, and inlined all of the scaling math into the top-level VI. In the process, I removed all of the CAN code, as we don’t use CAN. The new VI only has two VI calls. I did the same with the Analog Read and Servo Set VI’s, but the gains are marginal for those compared to the Motor Set VI.

The big picture: With the modifications of this VI, we saved approx. 25% CPU load. With the Analog and Servo (not posted), we saved an additional 6% CPU. All numbers were taken with temporarily running code, with the same VI front panels open, using the RT Get System CPU Loads VI called every 1000ms and displaying the information to the front panel.

This VI is a drop-in replacement for WPI Set Motor for all teams using PWM. No CAN support exists or is planned. Use at your own risk; we ran this at Kettering without issue.

SimpleSetMotor.vi (33.4 KB)


SimpleSetMotor.vi (33.4 KB)

That’s pretty sweet. No way we’re using it without an off-season vetting period, but for the future that could be awfully handy, especially for those of us still using an 8-slot CRio!

These are some really good observations - I’ve spent a good portion of the last few meetings trying to optimize our code and get CPU usage down. I’ll be sure to look through that VI and play with it in the upcoming days. I think it can make a sizable difference.

(You must spread some Reputation around before giving it to apalrd again.)