Go to Post you should see my scout sheet its the bomb diggity - Mirza95vx [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 12-02-2016, 11:44
blturner blturner is offline
Registered User
FRC #5013 (Trobots)
Team Role: Mentor
 
Join Date: Nov 2011
Rookie Year: 2006
Location: Kansas City
Posts: 27
blturner is on a distinguished road
nagging problem with CPU usage

Our robot drives fine and we are not getting any errors on the drivers station but the CPU is 80% disabled and bumps 100% while enabled. it's hard to read this on the drivers station graph.(Perhaps there is a better place?)
I have looked for untimed while loops and can't find any. I slowed down all of our periodic task loops and that does not seem to make any difference.
We have poor update rates while in debug mode. Sometimes the front panel displays will be as much as 3 seconds behind reality and can be choppy. That makes it hard to trouble shoot and tune our PID loops.

Rebooting everything helps but the problems come back.
When I check the vi timings it says that various CAN bus subVIs from the WPIlib are using a lot of milliseconds of processing time. The fact that we have not touched these VIs and that it seems to be reporting more milliseconds than have passed or even would be available makes me think the report is in error. I believe it was reporting about 5 minutes of CPU usage only about 30 seconds after we deployed the code.

We are running 4 Talon SRX controllers on the CAN bus. We have them on different IDs. I have not checked them for sticky errors. I don't know what firmware they are running. I can't see how that would effect the RoboRIO CPU usage, but I have been reading that is the pat answer to anything having to do with them. I will check next time the team meets.

What I don't know is what normal CPU usage would be for the default code. How fast should our drive loop be in periodic tasks? 10,20 or 40 ms? The drive loop is our biggest piece of code and it seems small.

Is this normal? Will it bite us at competition? We had that happen in the past.

Is it Wifi interference? We have tried 5ghz and ethernet connection but nothing seems conclusive. Of course we are cramped for time, so I don't want to spend a lot chasing something that is not really a problem. But if this is an indication of something terribly wrong then I can move the issue to the top of the list.

I can post our code, but I don't know if I should post all of it or just the VIs in question. Well here's the whole folder.
https://www.dropbox.com/sh/rbo96razt...JWglOHvMa?dl=0

Thanks,
Brian
  #2   Spotlight this post!  
Unread 12-02-2016, 11:54
SenorZ's Avatar
SenorZ SenorZ is offline
Physics Teacher
AKA: Tom Zook
FRC #4276 (Surf City Vikings)
Team Role: Teacher
 
Join Date: Jan 2011
Rookie Year: 2011
Location: Huntington Beach, California
Posts: 946
SenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond reputeSenorZ has a reputation beyond repute
Re: nagging problem with CPU usage

So, you're running LabView in the background while running driver station?
It's been a few years since I used LV, but I recall it being very resource heavy.
__________________
2013-present: FRC Team 4276, Surf City Vikings
2011-2012: FRC Team 3677, The Don Bots
  #3   Spotlight this post!  
Unread 12-02-2016, 12:08
Jared's Avatar
Jared Jared is offline
Registered User
no team
Team Role: Programmer
 
Join Date: Aug 2013
Rookie Year: 2012
Location: Connecticut
Posts: 602
Jared has a reputation beyond reputeJared has a reputation beyond reputeJared has a reputation beyond reputeJared has a reputation beyond reputeJared has a reputation beyond reputeJared has a reputation beyond reputeJared has a reputation beyond reputeJared has a reputation beyond reputeJared has a reputation beyond reputeJared has a reputation beyond reputeJared has a reputation beyond repute
Re: nagging problem with CPU usage

Try putting a disable structure over all of your code, verify the CPU usage drops to a normal value, then one by one take your VI's out of the disable structure to see what's causing the increase.
  #4   Spotlight this post!  
Unread 12-02-2016, 12:25
blturner blturner is offline
Registered User
FRC #5013 (Trobots)
Team Role: Mentor
 
Join Date: Nov 2011
Rookie Year: 2006
Location: Kansas City
Posts: 27
blturner is on a distinguished road
Re: nagging problem with CPU usage

Quote:
Originally Posted by Jared View Post
Try putting a disable structure over all of your code, verify the CPU usage drops to a normal value, then one by one take your VI's out of the disable structure to see what's causing the increase.
What is Normal Usage? The default code does so much that normal might be 80% I just don't know.
  #5   Spotlight this post!  
Unread 12-02-2016, 12:30
aeastet aeastet is offline
Programming Mentor
AKA: Tim Easterling
FRC #6043 (Allegan Tigers Robotics)
Team Role: Coach
 
Join Date: Jan 2015
Rookie Year: 2011
Location: Holland, MI
Posts: 130
aeastet is an unknown quantity at this point
Re: nagging problem with CPU usage

One of the biggest things that I see that is causing problems is that you have vision on the RoboRio. This is a major resource hog and has nothing to do with LabVIEW.

You should look at moving this vision stuff to the Dashboard. It is not that hard to do. That would help you a lot with your RoboRio resources.

There are many other things that I see that would help with lowering resources. One thing is using global variables. They take a windows call to set priority. This will slow down what you are doing. We use action engines to hold the values that we want to use in other places. Look at our code from last year to see what I am talking about.

I would move all of the dashboard updates to their own loop in the timed tasks. Have one loop that sends and receives values and put them into global variables if you do not have time to lean action engines. Can I edit your code on line? I could try and show you what I am talking about.

Biggest thing you can do is move the vision stuff to the dashboard hands down.
  #6   Spotlight this post!  
Unread 12-02-2016, 12:56
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,756
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: nagging problem with CPU usage

I didn't look at the code yet, but I'll try to answer some of your questions.

Normal for default code is somewhere around 15% to 25% depending on PWM or CAN, the number of sensors and actuators you are updating in teleOp or a fast periodic task, and how many variables you are publishing.

If you have panels open, they also take CPU to send the updates the debug panel.

The first thing I'd do is build an EXE, deploy and run as startup and use the DS to see what the numbers are as you use the robot in TeleOp and other modes. If you want to see more detail, you can connect to the roboRIO web page and scroll down the screen and you will see detailed CPU numbers.

If they seem high, slow down or disable vision to isolate it from the rest of the robot. Personally, I think vision on the roboRIO is not that bad, but running it on the dashboard is a fine solution too.

Global variables make it quite easy to have a race condition, but I wouldn't pin them as a common source of performance problems. They are atomic, meaning the a mutex is needed, but I wouldn't describe that as a windows call to set priorities. Again, once vision is removed, you can more clearly see what remains.

Common problems are ... running loops faster than needed (which includes no wait at all), calling CAN nodes inside the loop when they only need to be set once, setting a NT variable more often than needed, doing excessive logging or print message reporting in a loop, etc. Vision is typically slow because the image is too big.

Greg McKaskle
  #7   Spotlight this post!  
Unread 12-02-2016, 17:26
aeastet aeastet is offline
Programming Mentor
AKA: Tim Easterling
FRC #6043 (Allegan Tigers Robotics)
Team Role: Coach
 
Join Date: Jan 2015
Rookie Year: 2011
Location: Holland, MI
Posts: 130
aeastet is an unknown quantity at this point
Re: nagging problem with CPU usage

I looked at your code an spent some time changing a few things. If you PM me I will figure out how to get you the updated version. I added some action engines so you can see how they are used. They are simple to use and can save a lot of time. I cleaned some stuff up and reorganized a few things.

I did notice that you are talking to the Arm UpDown in two places. You should try to keep the writing part of your code in one place. There are other things to do that could help but I do have a day job. I will be out this weekend so I will have to get you the update on Monday if you would like to see it.

Tim
  #8   Spotlight this post!  
Unread 12-02-2016, 18:17
blturner blturner is offline
Registered User
FRC #5013 (Trobots)
Team Role: Mentor
 
Join Date: Nov 2011
Rookie Year: 2006
Location: Kansas City
Posts: 27
blturner is on a distinguished road
Re: nagging problem with CPU usage

Aeastet, Thanks for spending time on the code. I don't know what an Action Engine is. Looking forward to seeing what you mean.

Greg, "calling CAN nodes inside the loop when they only need to be set once"
This sounds like a mistake I could be making. I will google it.

Default code 15 to 25% That means that yes I have a problem I need to fix.

We are not doing vision in the RoboRIO. We are doing it in roborealm on a tablet on the robot. What you see is just the processing of the X and Y Roborealm found into commands to turn and fire.

I figured that global variables would be fast. We are using a lot of them this year. I don't know what a windows call to set priority means. More to google.

The WPI method of calling a subVI always seemed like more work than global variables. And we had a problem last year where we could not call the same subVI at the same time and get reliable results. We had to tie the errors from one to the next so they would not run in parallel. But I suspect that is all just minor compared to our problem. Our code just is not that complex.

I will check the arm up down in two places I thought I put the first one in a false case when the second one was running.(autofire is true)
  #9   Spotlight this post!  
Unread 13-02-2016, 08:41
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,756
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: nagging problem with CPU usage

I ran your code on my roboRIO and the disabled CPU load was about 30% and teleOp was about 60%. Of course I don't have the CAN devices or RoboRealm running on a tablet, so I'm getting lots of errors and may not be running some of the code. In the profiler, the biggest contributor was the CAN updates.

As a test, I converted the CAN Talon SRX in Begin into a PWM Talon SRX and the numbers changed to 20% and 40%. Of course there were still lots of error, and different errors, but in general, using CAN when the Talon is in power mode, the equivalent of PWMs, will be more expensive. Until this is on a real robot with a true CAN network, I don't trust my numbers much, but this may be a pretty easy experiments for you to run.

Using CAN for velocity control, position control, or other things that cannot be done easily with PWM is certainly worth it, but there is additional overhead to CAN, and for PWM, it will somewhat your CPU usage.

Greg McKaskle

Last edited by Greg McKaskle : 13-02-2016 at 09:03. Reason: A bit more on CAN
  #10   Spotlight this post!  
Unread 13-02-2016, 09:31
BenGuy's Avatar
BenGuy BenGuy is offline
Co-Driver - 3641 - Flying Toasters
AKA: Ben
FRC #3641 (The Flying Toasters)
Team Role: Operator
 
Join Date: May 2014
Rookie Year: 2014
Location: South Lyon, Michigan
Posts: 219
BenGuy is a glorious beacon of lightBenGuy is a glorious beacon of lightBenGuy is a glorious beacon of lightBenGuy is a glorious beacon of lightBenGuy is a glorious beacon of lightBenGuy is a glorious beacon of light
Re: nagging problem with CPU usage

We had that problem when we used older computers. If you don't need the dashboard, I'd suggest closing that down because that lightened the load to a normal amount on our older computers. Also make sure you don't have any unwanted programs hogging the cpu.
__________________



Ben Wolak
The Flying Toasters Website

Team YouTube
Team Twitter

The real problem with computers is that they do what you tell them to do, not what you want them to do.
  #11   Spotlight this post!  
Unread 13-02-2016, 10:37
MikLast's Avatar
MikLast MikLast is offline
CAO/Drive Coach
AKA: Mikal Dieatrick
FRC #4513 (Circuit Breakers)
Team Role: Leadership
 
Join Date: Jan 2015
Rookie Year: 2014
Location: Medical Lake, WA
Posts: 597
MikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond repute
Re: nagging problem with CPU usage

What processor do you have? (look up system information in the start menu, and in the "hardware summary" there should be a row labeled "Processor." i want the full name.)

Also, if you are running windows 8/10, in the task manager there is a place to see the CPU, GPU, RAM, Disk, and WiFi usage. See if those line up.
__________________

Check out the FRC Discord!

2014: programmer, scout
2015: programmer, admin, drive team
Innovation in control award, WVHS district event
Innovation in control award, CWU district event
finalist, PNW district championship
2016: CAO, Drive team.
Excellence In Engineering awad, WVHS District event
  #12   Spotlight this post!  
Unread 13-02-2016, 11:17
BariSaxGuy's Avatar
BariSaxGuy BariSaxGuy is offline
$@#$@#$@#$@#$@#
FRC #5013 (Trobots)
Team Role: Programmer
 
Join Date: Oct 2013
Rookie Year: 2013
Location: Kansas City, MO
Posts: 35
BariSaxGuy is an unknown quantity at this point
Re: nagging problem with CPU usage

BenWolak-It is the RoboRio CPU usage, and we believe, not the computer's.

MikLast- I doubt that the computer's processor is going to have any problems. It's a MacBook Pro running Windows 8.1 through BootCamp. It has a Core
i7-4750HQ CPU, 2.00 Ghz, and 8 GB of RAM. Nothing else is out of the ordinary, except the RoboRio CPU usage.
  #13   Spotlight this post!  
Unread 13-02-2016, 12:20
MikLast's Avatar
MikLast MikLast is offline
CAO/Drive Coach
AKA: Mikal Dieatrick
FRC #4513 (Circuit Breakers)
Team Role: Leadership
 
Join Date: Jan 2015
Rookie Year: 2014
Location: Medical Lake, WA
Posts: 597
MikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond reputeMikLast has a reputation beyond repute
Re: nagging problem with CPU usage

Quote:
Originally Posted by BariSaxGuy View Post
MikLast- I doubt that the computer's processor is going to have any problems. It's a MacBook Pro running Windows 8.1 through BootCamp. It has a Core
i7-4750HQ CPU, 2.00 Ghz, and 8 GB of RAM. Nothing else is out of the ordinary, except the RoboRio CPU usage.
No, i also would not think that is the issue. Is there any other computers to test with then? as Senor said, try getting out of any other program. Try and figure out if its an issue in the code or the computer itself.
__________________

Check out the FRC Discord!

2014: programmer, scout
2015: programmer, admin, drive team
Innovation in control award, WVHS district event
Innovation in control award, CWU district event
finalist, PNW district championship
2016: CAO, Drive team.
Excellence In Engineering awad, WVHS District event
  #14   Spotlight this post!  
Unread 13-02-2016, 20:48
blturner blturner is offline
Registered User
FRC #5013 (Trobots)
Team Role: Mentor
 
Join Date: Nov 2011
Rookie Year: 2006
Location: Kansas City
Posts: 27
blturner is on a distinguished road
Re: nagging problem with CPU usage

Greg. We were having problems deploying the code. Different errors and it takes several tries. I think the lead programmer did get it deployed so it would run at startup. I was to tired to remember to check the CPU usage.
I was also distracted by the fact that our auto targeting system did start working pretty much as planned today.

We do have both another RoboRIO and another computer we can try from if it still has the issue when deployed.

We plan on working tomorrow so I will check it in the morning.
  #15   Spotlight this post!  
Unread 14-02-2016, 09:54
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,756
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: nagging problem with CPU usage

If you are using a navX, you may want to get the latest libraries. There was a subtle issue that caused deployment problems on every other run. This isn't obvious, and it is easy to misinterpret the issue. I don't know of other specific deployment problems. If you have specific error messages, please post them.

Greg McKaskle
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 01:31.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi