![]() |
Re: Team Update - 2012-03-13
Quote:
Quote:
|
Re: Team Update - 2012-03-13
Quote:
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. |
Re: Team Update - 2012-03-13
1 Attachment(s)
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. |
Re: Team Update - 2012-03-13
Quote:
|
Re: Team Update - 2012-03-13
Quote:
(You must spread some Reputation around before giving it to apalrd again.) |
Re: Team Update - 2012-03-13
Not to (slightly) derail the thread again, @FRCTeams (Bill Miller's Twitter) tweeted the following about 15 minutes ago:
Quote:
|
Re: Team Update - 2012-03-13
Quote:
Quote:
|
Re: Team Update - 2012-03-13
Quote:
|
Re: Team Update - 2012-03-13
Quote:
|
Re: Team Update - 2012-03-13
Quote:
|
Re: Team Update - 2012-03-13
Quote:
The intent behind the white bridge, and a message that says, in effect, "We are concerned about the reports we have been hearing. Actions like we have been hearing about are frowned upon." There is no explicit penalty given, but with that sort of statement, [G15] could reasonably be applied for uncivil conduct during a match. |
Re: Team Update - 2012-03-13
And that's the end of that.
|
Re: Team Update - 2012-03-13
Quote:
The WPILib implementation is indeed pretty heavy. I was able to make small safe enhancements during beta, but due to timing, I could only knock off the biggest issues. At that point, CAN had a call that was quite expensive, and the named registration for RobotDrive was not inplace. I would have liked to do more, and fully intend to do so over the next break. On the other hand, this is by no means the deep internals of LV, and if by tasking system for each VI, you mean a thread, that is not how scheduling in LV works. I'll be happy to go into more detail, but again, the LV section is a better place to go deeper on this. While the default framework uses the high level WPILib and regular loops and simple globals, there is certainly no issue with you making mods and using fancier language elements. In fact, that was part of the reason for writing it in source for each language. Thanks for publishing this, and if you want to go deeper and see how much the various edits saved, please open it up on the LV section. Greg McKaskle |
Re: Team Update - 2012-03-13
Quote:
I hope you are going to St. Louis, because I have a whole group who would like to thank you personally! Thank you!!! |
| All times are GMT -5. The time now is 17:53. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi